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Real party in interest 

Asset Reliance, Inc. (dba Asset Trust, h 
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Related appeals 

An appeal for U.S. Patent Application 10/282,113 filed October 29, 2002 may be affected by or 
have a bearing on this appeal. An appeal for U.S. Patent Application 09/761,670 filed January 18, 
2001 may be affected or have a bearing on this appeal. An appeal for U.S. Patent Application 
09/761,671 filed January 18, 2001 may be affected or have a bearing on this appeal. An Appeal 
for U.S. Patent Application 09/940,450 filed on August 29, 2001 may be affected by or have a 
bearing on this appeal. 
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Status of Claims 

Claims 44 - 59 and 65 - 81 are rejected and are the subject of this appeal. Claims 1 - 43 and 60 - 
64 are cancelled without prejudice. Claim 82 is withdrawn. 
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Status of Amendments 

An Amendment/Reply was submitted on April 1, 2007. 
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Summary of Claimed Subject Matter 

One embodiment of a method of and system for analyzing, modeling and valuing elements 
of a business enterprise according to the present invention is best depicted in Figures 1 - 15 of the 
specification for the instant application. Figure 1 gives an overview of the major processing steps 
which include converting and storing data from a plurality of database management systems for 
use in analysis, analyzing the data as required to: optionally value growth options, identify value 
drivers by element of value, develop predictive models for each component of value and value the 
elements of value. 

Independent Claim 44 - One embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 44 where a program storage 
device guides the conversion and storage of data aggregated from a plurality of management 
systems in accordance with a common schema for use in processing. More specifically, data from 
the database management systems associated with a plurality of enterprise transaction systems 
are aggregated and stored in one or more tables or files in accordance with a network schema as 
described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference 
numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 
through 720 - n and 730 and line 16, page 18 through line 16, page 35 of the specification. 

Dependent claims 

The limitations associated with dependent claim 45 are described in several places 
including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and 
Table 16, page 31 of the specification. 

The limitations associated with dependent claim 46 are described in several places 
including line 16, page 56 through line 9, page 59 of the specification. 

The limitations associated with dependent claim 47 are described in several places 
including table 1, page 9, and Table 16, page 31 of the specification. 

The limitations associated with dependent claim 48 are described in line 1, page 26 through 
line 14, page 26. 

The limitations associated with dependent claim 49 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 50 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification.. 

The limitations associated with dependent claim 51 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 52 are described in a variety of places 
including FIG. 10. 

Independent Claim 53 - A second embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 53 where a method converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
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schema for use in processing. More specifically, data from the database management systems 
associated with a plurality of enterprise transaction systems are aggregated and stored in one or 
more tables or files in accordance with a network schema as described FIG. 1 reference number 
200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 223, 225 - 230, FIG. 
10 reference numbers 710 - 1 through 710 - n, 720-1 through 720 - n and 730 and line 16, page 
18 through line 16, page 35 of the specification. 

Dependent claims 

The limitations associated with dependent claim 54 are described in several places 
including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and 
Table 16, page 31 of the specification. 

The limitations associated with dependent claim 55 are described in several places 
including table 1, page 9, and Table 16, page 31 of the specification. 

The limitations associated with dependent claim 56 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 57 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification.. 

The limitations associated with dependent claim 58 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 59 are described in several places 
including FIG. 10. 

Independent Claim 65 - A third embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 65 where a method converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema for use in analysis and modeling. More specifically, data from the database management 
systems associated with a plurality of enterprise transaction systems are aggregated and stored in 
one or more tables or files in accordance with a network schema as described FIG. 1 reference 
number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 223, 225 - 
230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 through 720 - n and 730 and line 
16, page 18 through line 16, page 35 of the specification. 

Dependent claim 

The limitations associated with dependent claim 66 are described in several places 
including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and 
Table 16, page 31 of the specification. 

Independent Claim 67 - A fourth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 67 where a computer 
readable medium guides the integration of data from a plurality of management systems in 
accordance with a common schema for use in processing. More specifically, data dictionaries from 
the database management systems associated with a plurality of enterprise transaction systems 
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are obtained, relationships between the newly obtained data dictionaries and an application data 
dictionary are identified, these relationships are then used to guide the conversion and storage of 
data in one or more tables or files in accordance with a common schema in a common database 
as described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B 
reference numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 
720-1 through 720 - n and 730 and line 16, page 18 through line 16, page 35 of the specification. 

Dependent claims 

The limitations associated with dependent claim 68 are described in several places 
including FIG. 10. 

The limitations associated with dependent claim 69 are described in several places 
including FIG. 10. 

The limitations associated with dependent claim 70 are described in several places 
including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and 
Table 16, page 31 of the specification. 

Independent claim 71 - A fifth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 71 where a system converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema for use in processing. More specifically, data dictionaries from the database management 
systems associated with a plurality of enterprise transaction systems are obtained, relationships 
between the newly obtained data dictionaries and an application data dictionary are identified, 
these relationships are then used to guide the conversion and storage of data in one or more 
tables or files in accordance with a common schema in a common database as described FIG. 1 
reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 
223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 through 720 - n and 
730 and line 16, page 18 through line 16, page 35 of the specification. 

Dependent claims 

The limitations associated with dependent claim 72 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. It is well known to those of average skill in the art that the databases for the listed 
systems are typically relational database systems. 

The limitations associated with dependent claim 73 are described in several places 
including FIG. 1, reference number 25 and line 15, page 12 through line 16 page 12 of the 
specification. 

The limitations associated with dependent claim 74 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 75 are described in several places 
including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and 
Table 16, page 31 of the specification. 

The limitations associated with dependent claim 76 are described in several places 
including line 12, page 8 through line 22, page 8 of the specification. 
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Independent claim 77 A sixth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 77 where a method converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema for use in processing. More specifically, data dictionaries from the database management 
systems associated with a plurality of enterprise transaction systems are obtained, relationships 
between the newly obtained data dictionaries and an application data dictionary are identified, 
these relationships are then used to guide the conversion and storage of data in one or more 
tables or files in accordance with a common schema in a common database as described FIG. 1 
reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 
223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 through 720 - n and 
730 and line 16, page 18 through line 16, page 35 of the specification. 

Dependent claims 

The limitations associated with dependent claim 78 are described in several places 
including FIG. 1, reference number 25 and line 15, page 12 through line 16 page 12 of the 
specification. 

The limitations associated with dependent claim 79 are described in several places 
including FIG. 1, reference number 5 and line 20, page 12 of the specification. 

The limitations associated with dependent claim 80 are described in several places 
including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and 
Table 16, page 31 of the specification. 

The limitations associated with dependent claim 81 are described in several places 
including table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 
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Grounds of rejection to be reviewed on appeal 

Issue 1 - Whether claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, claim 51 
and claim 52 are patentable under 35 USC 102 over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

Issue 2 - Whether claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and claim 59 are 
patentable under 35 USC 102 over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

Issue 3 - Whether claim 65 and claim 66 are patentable under 35 USC 102 over U.S. Patent 
4,989,141 (hereinafter, Lyons)? 

Issue 4 - Whether claim 67, claim 68, claim 69 and claim 70 are patentable under 35 USC 102 
over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

Issue 5 - Whether claim 71, claim 72, claim 73, claim 74, claim 75 and claim 76 are patentable 
under 35 USC 102 over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

Issue 6 - Whether claim 77, claim 78, claim 79, claim 80 and claim 81 are patentable under 35 
USC 102 over U.S. Patent 4,989,141 (hereinafter, Lyons)? 
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The Argument 



Grouping of Claims 

For each ground of rejection which Appellant contests herein which applies to more than one 
claim, such additional claims, to the extent separately identified and argued below, do not stand 
and fall together. 

Issue 1 - Whether claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, claim 
51 and claim 52 are patentable under 35 USC 102 over U.S. Patent 4,989,141 (hereinafter, 
Lyons)? 

The claims are patentable for several reasons. One of the primary reasons is that the Lyons 
document and the arguments related to the Lyons document fail to establish a prima facie case of 
anticipation in a number of ways for every rejected claim. 

One way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to describe every element of 
the rejected claims. MPEP 2131 notes that: "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). 

Another way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to provide the same level of 
detail that is present in the claim. MPEP 2131 notes that anticipation requires that: "The identical 
invention must be shown in as complete detail as is contained in the ... claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

A third way in which the arguments related to the Lyons document fail to establish a prima 
facie case of anticipation for many if not all of the claims is there has been no disclosure of fact or 
technical reasoning that would support any allegations regarding inherent characteristics contained 
in the Lyons document. MPEP 2112 notes that: "In relying upon the theory of inherency, the 
Examiner must provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
applied prior art." Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) 

The Appellant respectfully submits that the rejection of independent claim 44 can be traversed 
in four ways. The first way is by noting that several elements of claim 44 are not explicitly 
described in the Lyons document. The elements not explicitly described include: 

1 . a common schema - the term is not mentioned, 

2. storing data in files or tables - Lyons uses a central data store that stores data in 
accordance with a predetermined pattern relative to a given SEPT value (see page 37, 
Evidence Appendix, Lyons C2, L45 - 50) and does not mention storing data in files or 
tables, and 

3. aggregating data from a plurality of database management systems - the Lyons disclosure 
does not mention "database management systems". 

The second way is by noting that Lyons lacks detail regarding a common schema, storing data in 
files or tables and aggregating enterprise related data from a plurality of database management 
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systems. The third way is by noting that any inherency of a common schema, storing data in files 
or tables and/or aggregating enterprise related data from a plurality of database management 
systems has not been explained. A fourth way of traversing the claim rejection is to note that the 
storage of data in files or tables is not enabled by Lyons . Everest (a reference provided by the 
Examiner) teaches that databases that store data in files or tables use a finite number of logical 
data structures (see pages 40 - 48, Evidence Appendix). The Lyons database does not use any of 
these logical data structures (see page 37, Evidence Appendix, Lyons C2, L45 - 50); therefore, 
Lyons does not enable the storage of data in files or tables. The Appellant notes that there are still 
other ways in which the §102 rejection of claim 44 can be traversed. As a result of these 
deficiencies, a prima facie case that would support the anticipation rejection of claim 44 has not 
been established. 

The Appellant respectfully submits that the rejection of dependent claim 45 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 44, does not enable all the 
elements of parent claim 44, provides insufficient detail regarding elements of parent claim 44 and 
that any alleged inherency of features of parent claim 44 has not been explained. The rejection of 
dependent claim 45 can also be traversed by noting that Lyons: is missing elements contained in 
claim 45, does not enable all the elements of claim 45, provides insufficient detail regarding 
elements of claim 45, that any alleged inherency of features of claim 45 has not been explained 
and that . Elements of claim 45 not explicitly described in the Lyons document include a common 
data dictionary, categories of value, elements of value, and units of measure. Lyons also lacks 
detail regarding a common data dictionary, categories of value, elements of value, and units of 
measure and any inherency of a common data dictionary, categories of value, elements of value, 
and units of measure has not been explained. Lyons also fails to enable categories of value, 
elements of value and units of measure. Lyons is limited to storing and manipulating information 
that appears in financial schedules (see page 37, Evidence Appendix, Lyons C2, L45 - 50). It is 
well known to those of average skill in the art that financial schedules do not include the elements 
of value, categories of value and units of measure. Given these facts, it is clear that elements of 
value, categories of value and units of measure cannot be supported by Lyons. As a result of 
these deficiencies, a prima facie case that would support the anticipation rejection of claim 45 has 
not been established. 

The Appellant respectfully submits that the rejection of dependent claim 46 can be traversed 
by noting that Lyons: is missing elements contained in parent claims 44 and 45, does not enable all 
the elements of parent claims 44 and 45, provides insufficient detail regarding elements of parent 
claims 44 and 45 and that any alleged inherency of features of parent claims 44 and 45 has not 
been explained. The rejection of dependent claim 46 can also be traversed by noting that Lyons: 
is missing elements contained in claim 46, does not enable all the elements of claim 46, provides 
insufficient detail regarding elements of claim 46 and that any alleged inherency of features of 
claim 46 has not been explained. Elements of claim 46 not explicitly or inherently described in the 
Lyons document include capital change. Lyons also lacks detail regarding capital change and any 
inherency of a capital change has not been explained. As a result of these deficiencies, a prima 
facie case that would support the anticipation rejection of claim 46 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 47 can be traversed 
by noting that Lyons: is missing elements contained in parent claims 44 and 45, does not enable all 
the elements of parent claims 44 and 45, provides insufficient detail regarding elements of parent 
claims 44 and 45 and that any alleged inherency of features of parent claims 44 and 45 has not 
been explained. The rejection of dependent claim 47 can also be traversed by noting that Lyons: 
is missing elements contained in claim 47, does not enable all the elements of claim 47, provides 
insufficient detail regarding elements of claim 47 and that any alleged inherency of features of 
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claim 47 has not been explained. Elements of claim 47 not explicitly or inherently described in the 
Lyons document include brands, customers, employees, production equipment, strategic 
partnerships, vendor relationships. Lyons also lacks detail regarding brands, customers, 
employees, production equipment, strategic partnerships, vendor relationships and any inherency 
of brands, customers, employees, production equipment, strategic partnerships, vendor 
relationships has not been explained. Lyons also fails to enable brands, customers, employees, 
strategic partnerships and vendor relationships. Lyons is limited to storing and manipulating 
information that appears in financial schedules (see page 37, Evidence Appendix, Lyons C2, L45 - 
50). It is well known to those of average skill in the art that financial schedules do not include 
brands, customers, employees, strategic partnerships, and vendor relationships. Given these 
facts, it is clear that brands, customers, employees, strategic partnerships, and vendor 
relationships cannot be supported by Lyons. As a result of these deficiencies, a prima facie case 
that would support the anticipation rejection of claim 47 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 48 can be traversed 
by noting that Lyons: is missing elements contained in parent claims 44 and 45, does not enable all 
the elements of parent claims 44 and 45, provides insufficient detail regarding elements of parent 
claims 44 and 45 and that any alleged inherency of features of parent claims 44 and 45 has not 
been explained. The rejection of dependent claim 48 can also be traversed by noting that Lyons: 
is missing elements contained in claim 48, does not enable all the elements of claim 48, provides 
insufficient detail regarding elements of claim 48 and that any alleged inherency of features of 
claim 48 has not been explained. Elements of claim 48 not explicitly or inherently described in the 
Lyons document sequential points in time. Lyons also lacks detail regarding sequential points in 
time and any inherency of sequential points in time has not been explained. As a result of these 
deficiencies, a prima facie case that would support the anticipation rejection of claim 48 has not 
been established. 

The Appellant respectfully submits that the rejection of dependent claim 49 can be traversed 
by noting that Lyons: is missing elements contained in parent claims 44, 45 and 48, does not 
enable all the elements of parent claims 44, 45 and 48, provides insufficient detail regarding 
elements of parent claims 44, 45 and 48 and that any alleged inherency of features of parent 
claims 44, 45 and 48 has not been explained. The rejection of dependent claim 49 can also be 
traversed by noting that Lyons: is missing elements contained in claim 49, does not enable all the 
elements of claim 49, provides insufficient detail regarding elements of claim 49 and that any 
alleged inherency of features of claim 49 has not been explained. Elements of claim 49 not 
explicitly or inherently described in the Lyons document include forecast event data and historical 
event data. Lyons also lacks detail regarding forecast event data and historical event data and any 
inherency of forecast event data and historical event data has not been explained. Lyons also fails 
to enable forecast event data and historical event data. Lyons is limited to storing and 
manipulating information that appears in financial schedules (see page 37, Evidence Appendix, 
Lyons C2, L45 - 50). It is well known to those of average skill in the art that financial schedules do 
not include forecast event data and historical event data. Given these facts, it is clear that forecast 
event data and historical event data cannot be supported by Lyons. As a result of these 
deficiencies, a prima facie case that would support the anticipation rejection of claim 49 has not 
been established. 

The Appellant respectfully submits that the rejection of dependent claim 50 can be traversed 
by noting that Lyons: is missing elements contained in parent claims 44, 45, 48 and 49, does not 
enable all the elements of parent claims 44, 45, 48 and 49, provides insufficient detail regarding 
elements of parent claims 44, 45, 48 and 49 and that any alleged inherency of features of parent 
claims 44, 45, 48 and 49 has not been explained. The rejection of dependent claim 50 can also be 
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traversed by noting that Lyons: is missing elements contained in claim 50, does not enable all the 
elements of claim 50, provides insufficient detail regarding elements of claim 50 and that any 
alleged inherency of features of claim 50 has not been explained. Elements of claim 50 not 
explicitly or inherently described in the Lyons document include transaction data. Lyons also lacks 
detail regarding transaction data and any inherency of transaction data has not been explained. 
Lyons also fails to enable transaction data. Lyons is limited to storing and manipulating information 
that appears in financial schedules (see page 37, Evidence Appendix, Lyons C2, L45 - 50). It is 
well known to those of average skill in the art that financial schedules do not include transaction 
data. Given these facts, it is clear that transaction data cannot be supported by Lyons. As a result 
of these deficiencies, a prima facie case that would support the anticipation rejection of claim 50 
has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 51 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 44, does not enable all the 
elements of parent claim 44, provides insufficient detail regarding elements of parent claim 44 and 
that any alleged inherency of features of parent claim 44 has not been explained. The rejection of 
dependent claim 51 can also be traversed by noting that Lyons: is missing elements contained in 
claim 51, does not enable all the elements of claim 51, provides insufficient detail regarding 
elements of claim 51 and that any alleged inherency of features of claim 51 has not been 
explained. Elements of claim 51 not explicitly or inherently described in the Lyons document 
include operation management systems, sales management systems, human resource systems, 
accounts receivable systems, accounts payable systems, capital asset systems, inventory 
systems, invoicing systems, payroll systems, purchasing systems and the Internet. Lyons also 
lacks detail regarding operation management systems, sales management systems, human 
resource systems, accounts receivable systems, accounts payable systems, capital asset systems, 
inventory systems, invoicing systems, payroll systems, purchasing systems and the Internet and 
any inherency of operation management systems, sales management systems, human resource 
systems, accounts receivable systems, accounts payable systems, capital asset systems, 
inventory systems, invoicing systems, payroll systems, purchasing systems and the Internet has 
not been explained. As a result of these deficiencies, a prima facie case that would support the 
anticipation rejection of claim 51 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 52 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 44, does not enable all the 
elements of parent claim 44, provides insufficient detail regarding elements of parent claim 44 and 
that any alleged inherency of features of parent claim 44 has not been explained. The rejection of 
dependent claim 52 can also be traversed by noting that Lyons: is missing elements contained in 
claim 52, does not enable all the elements of claim 52, provides insufficient detail regarding 
elements of claim 52 and that any alleged inherency of features of claim 52 has not been 
explained. Elements of claim 52 not explicitly or inherently described in the Lyons document 
include a network model. Lyons also lacks detail regarding a network model and any inherency of 
a network model has not been explained. As a result of these deficiencies, a prima facie case that 
would support the anticipation rejection of claim 52 has not been established. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to 
produce the evidence required to establish a prima facie case of anticipation for a single claim. 
The complete failure to identify anticipation at the claim level clearly illustrates the fact that the 
cited reference is not even remotely similar to the invention described by claim 44, claim 45, claim 
46, claim 47, claim 48, claim 49, claim 50, claim 51 and claim 52. As noted in MPEP 2112, 
anticipation requires that a substantial identity be established. Taken together, these failures 
provide additional evidence that the claimed invention for producing concrete, tangible and useful 
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results is new, novel and non-obvious. 

Another reason claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, claim 51 
and claim 52 are patentable is that the prior art review for the instant application is apparently 
being completed under a different standard than that used for the review of similar patent 
applications - an apparent violation of 35 USC 3. As noted on page 46 in the evidence appendix 
and in the appeal brief for related application 10/282,113, the proper class for the invention 
described in these claims is class 707. The assignment to class 705 has resulted in considerable 
delay and the use of a different standard for prior art review than that used for similar applications 
properly classified in class 707. 

Issue 2 - Whether claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and claim 59 are 
patentable under 35 USC 102 over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

The claims are patentable for several reasons. One of the primary reasons is that the Lyons 
document and the arguments related to the Lyons document fail to establish a prima facie case of 
anticipation in a number of ways for every rejected claim. 

One way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to describe every element of 
the rejected claims. MPEP 2131 notes that: "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). 

Another way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to provide the same level of 
detail that is present in the claim. MPEP 2131 notes that anticipation requires that: "The identical 
invention must be shown in as complete detail as is contained in the ... claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

A third way in which the arguments related to the Lyons document fail to establish a prima 
facie case of anticipation for many if not all of the claims is there has been no disclosure of fact or 
technical reasoning that would support any allegations regarding inherent characteristics contained 
in the Lyons document. MPEP 2112 notes that: "In relying upon the theory of inherency, the 
Examiner must provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
applied prior art." Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) 

The Appellant respectfully submits that the rejection of independent claim 53 can be traversed 
in four ways. The first way is by noting that several elements of claim 53 are not explicitly 
described in the Lyons document. The elements not explicitly described include: 

1 . a common schema - the term is not mentioned, 

2. storing data in files or tables - Lyons uses a central data store that stores data in 
accordance with a predetermined pattern relative to a given SEPT value (see page 37, 
Evidence Appendix, Lyons C2, L45 - 50) and does not mention storing data in files or 
tables, and 

3. aggregating data from a plurality of database management systems - the Lyons disclosure 
does not mention "database management systems". 



Serial No: 08/999,245 



16 



The second way is by noting that Lyons lacks detail regarding a common schema, storing data in 
files or tables and aggregating enterprise related data from a plurality of database management 
systems. The third way is by noting that any inherency of a common schema, storing data in files 
or tables and/or aggregating enterprise related data from a plurality of database management 
systems has not been explained. A fourth way of traversing the claim rejection is to note that the 
storage of data in files or tables is not enabled by Lyons . Everest (a reference provided by the 
Examiner) teaches that databases that store data in files or tables use a finite number of logical 
data structures (see pages 40 - 48, Evidence Appendix). The Lyons database does not use any of 
these logical data structures (see page 37, Evidence Appendix, Lyons C2, L45 - 50); therefore, 
Lyons does not enable the storage of data in files or tables. The Appellant notes that there are still 
other ways in which the §102 rejection of claim 53 can be traversed. As a result of these 
deficiencies, a prima facie case that would support the anticipation rejection of claim 53 has not 
been established. 

The Appellant respectfully submits that the rejection of dependent claim 54 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 53, does not enable all the 
elements of parent claim 53, provides insufficient detail regarding elements of parent claim 53 and 
that any alleged inherency of features of parent claim 53 has not been explained. The rejection of 
dependent claim 54 can also be traversed by noting that Lyons: is missing elements contained in 
claim 54, does not enable all the elements of claim 54, provides insufficient detail regarding 
elements of claim 54 and that any alleged inherency of features of claim 54 has not been 
explained. Elements of claim 54 not explicitly or inherently described in the Lyons document 
include a common data dictionary, categories of value, elements of value, and units of measure. 
Lyons also lacks detail regarding a common data dictionary, categories of value, elements of 
value, and units of measure and any inherency of a common data dictionary, categories of value, 
elements of value, and units of measure has not been explained. Lyons also fails to enable 
categories of value, elements of value and units of measure. Lyons is limited to storing and 
manipulating information that appears in financial schedules (see page 37, Evidence Appendix, 
Lyons C2, L45 - 50). It is well known to those of average skill in the art that financial schedules do 
not include the elements of value, categories of value and units of measure. Given these facts, it is 
clear that elements of value, categories of value and units of measure cannot be supported by 
Lyons. As a result of these deficiencies, a prima facie case that would support the anticipation 
rejection of claim 54 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 55 can be traversed 
by noting that Lyons: is missing elements contained in parent claims 53 and 54, does not enable all 
the elements of parent claims 53 and 54, provides insufficient detail regarding elements of parent 
claims 53 and 54 and that any alleged inherency of features of parent claims 53 and 54 has not 
been explained. The rejection of dependent claim 55 can also be traversed by noting that Lyons: 
is missing elements contained in claim 55, does not enable all the elements of claim 55, provides 
insufficient detail regarding elements of claim 55 and that any alleged inherency of features of 
claim 55 has not been explained. Elements of claim 55 not explicitly or inherently described in the 
Lyons document include brands, customers, employees, production equipment, strategic 
partnerships, vendor relationships. Lyons also lacks detail regarding brands, customers, 
employees, production equipment, strategic partnerships, vendor relationships and any inherency 
of brands, customers, employees, production equipment, strategic partnerships, vendor 
relationships has not been explained. Lyons also fails to enable brands, customers, employees, 
strategic partnerships and vendor relationships. Lyons is limited to storing and manipulating 
information that appears in financial schedules (see page 37, Evidence Appendix, Lyons C2, L45 - 
50). It is well known to those of average skill in the art that financial schedules do not include 
brands, customers, employees, strategic partnerships, and vendor relationships. Given these 
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facts, it is clear that brands, customers, employees, strategic partnerships, and vendor 
relationships cannot be supported by Lyons. As a result of these deficiencies, a prima facie case 
that would support the anticipation rejection of claim 55 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 56 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 53, does not enable all the 
elements of parent claim 53, provides insufficient detail regarding elements of parent claim 53 and 
that any alleged inherency of features of parent claim 53 has not been explained. The rejection of 
dependent claim 56 can also be traversed by noting that Lyons: is missing elements contained in 
claim 56, does not enable all the elements of claim 56, provides insufficient detail regarding 
elements of claim 56 and that any alleged inherency of features of claim 56 has not been 
explained. Elements of claim 56 not explicitly or inherently described in the Lyons document 
include forecast event data and historical event data. Lyons also lacks detail regarding forecast 
event data and historical event data and any inherency of forecast event data and historical event 
data has not been explained. Lyons also fails to enable forecast event data and historical event 
data. Lyons is limited to storing and manipulating information that appears in financial schedules 
(see page 37, Evidence Appendix, Lyons C2, L45 - 50). It is well known to those of average skill 
in the art that financial schedules do not include forecast event data and historical event data. 
Given these facts, it is clear that forecast event data and historical event data cannot be supported 
by Lyons. As a result of these deficiencies, a prima facie case that would support the anticipation 
rejection of claim 56 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 57 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 53, does not enable all the 
elements of parent claim 53, provides insufficient detail regarding elements of parent claim 53 and 
that any alleged inherency of features of parent claim 53 has not been explained. The rejection of 
dependent claim 57 can also be traversed by noting that Lyons: is missing elements contained in 
claim 57, does not enable all the elements of claim 57, provides insufficient detail regarding 
elements of claim 57 and that any alleged inherency of features of claim 57 has not been 
explained. Elements of claim 57 not explicitly or inherently described in the Lyons document 
include transaction data. Lyons also lacks detail regarding transaction data and any inherency of 
transaction data has not been explained. Lyons also fails to enable transaction data. Lyons is 
limited to storing and manipulating information that appears in financial schedules (see page 37, 
Evidence Appendix, Lyons C2, L45 - 50). It is well known to those of average skill in the art that 
financial schedules do not include transaction data. Given these facts, it is clear that transaction 
data cannot be supported by Lyons. As a result of these deficiencies, a prima facie case that 
would support the anticipation rejection of claim 57 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 58 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 53, does not enable all the 
elements of parent claim 53, provides insufficient detail regarding elements of parent claim 53 and 
that any alleged inherency of features of parent claim 53 has not been explained. The rejection of 
dependent claim 58 can also be traversed by noting that Lyons: is missing elements contained in 
claim 58, does not enable all the elements of claim 58, provides insufficient detail regarding 
elements of claim 58 and that any alleged inherency of features of claim 58 has not been 
explained. Elements of claim 58 not explicitly or inherently described in the Lyons document 
include operation management systems, sales management systems, human resource systems, 
accounts receivable systems, accounts payable systems, capital asset systems, inventory 
systems, invoicing systems, payroll systems, purchasing systems and the Internet. Lyons also 
lacks detail regarding operation management systems, sales management systems, human 
resource systems, accounts receivable systems, accounts payable systems, capital asset systems, 
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inventory systems, invoicing systems, payroll systems, purchasing systems and the Internet and 
any inherency of operation management systems, sales management systems, human resource 
systems, accounts receivable systems, accounts payable systems, capital asset systems, 
inventory systems, invoicing systems, payroll systems, purchasing systems and the Internet has 
not been explained. As a result of these deficiencies, a prima facie case that would support the 
anticipation rejection of claim 58 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 59 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 53, does not enable all the 
elements of parent claim 53, provides insufficient detail regarding elements of parent claim 53 and 
that any alleged inherency of features of parent claim 53 has not been explained. The rejection of 
dependent claim 59 can also be traversed by noting that Lyons: is missing elements contained in 
claim 59, does not enable all the elements of claim 59, provides insufficient detail regarding 
elements of claim 59 and that any alleged inherency of features of claim 59 has not been 
explained. Elements of claim 59 not explicitly or inherently described in the Lyons document 
include a network model. Lyons also lacks detail regarding a network model and any inherency of 
a network model has not been explained. As a result of these deficiencies, a prima facie case that 
would support the anticipation rejection of claim 59 has not been established. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to 
produce the evidence required to establish a prima facie case of anticipation for a single claim. 
The complete failure to identify anticipation at the claim level clearly illustrates the fact that the 
cited reference is not even remotely similar to the invention described by claim 53, claim 54, claim 
55, claim 56, claim 57, claim 58 and claim 59. As noted in MPEP2112, anticipation requires that a 
substantial identity be established. Taken together, these failures provide additional evidence that 
the claimed invention for producing concrete, tangible and useful results is new, novel and non- 
obvious. 

Another reason claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and claim 59 are 
patentable is that the prior art review for the instant application is apparently being completed 
under a different standard than that used for the review of similar patent applications - an apparent 
violation of 35 USC 3. As noted on page 46 in the evidence appendix and in the appeal brief for 
related application 10/282,113, the proper class for the invention described in claims claim 53, 
claim 54, claim 55, claim 56, claim 57, claim 58 and claim 59 is class 707. The assignment to 
class 705 has resulted in the use of a different standard for prior art review than that used for 
similar applications properly classified in class 707. 

Issue 3 - Whether claim 65 and claim 66 are patentable under 35 USC 102 over U.S. Patent 
4,989,141 (hereinafter, Lyons)? 

The claims are patentable for several reasons. One of the primary reasons is that the Lyons 
document and the arguments related to the Lyons document fail to establish a prima facie case of 
anticipation in a number of ways for every rejected claim. 

One way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to describe every element of 
the rejected claims. MPEP 2131 notes that: "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). 

Another way in which the Lyons document fails to establish a prima facie case of anticipation for 
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many if not all of the rejected claims is that the Lyons document fails to provide the same level of 
detail that is present in the claim. MPEP 2131 notes that anticipation requires that: "The identical 
invention must be shown in as complete detail as is contained in the ... claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

A third way in which the arguments related to the Lyons document fail to establish a prima 
facie case of anticipation for many if not all of the claims is there has been no disclosure of fact or 
technical reasoning that would support any allegations regarding inherent characteristics contained 
in the Lyons document. MPEP 2112 notes that: "In relying upon the theory of inherency, the 
Examiner must provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
applied prior art." Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) 

The Appellant respectfully submits that the rejection of independent claim 65 can be traversed 
in four ways. The first way is by noting that several elements of claim 65 are not explicitly 
described in the Lyons document. The elements not explicitly described include: 

1 . a common schema - the term is not mentioned, 

2. storing data in files or tables - Lyons uses a central data store that stores data in 
accordance with a predetermined pattern relative to a given SEPT value (see page 37, 
Evidence Appendix, Lyons C2, L45 - 50) and does not mention storing data in files or 
tables, and 

3. aggregating event data from a plurality of database management systems - the Lyons 
disclosure does not mention "event data" or "database management systems". 

The second way is by noting that Lyons lacks detail regarding a common schema, storing data 
in files or tables and aggregating enterprise related event data from a plurality of database 
management systems. The third way is by noting that any inherency of a common schema, storing 
data in files or tables and/or aggregating enterprise related event data from a plurality of database 
management systems has not been explained. A fourth way of traversing the claim rejection is to 
note that the storage of data in files or tables is not enabled by Lyons . Everest (a reference 
provided by the Examiner) teaches that databases that store data in files or tables use a finite 
number of logical data structures (see pages 40 - 48, Evidence Appendix). The Lyons database 
does not use any of these logical data structures (see page 37, Evidence Appendix, Lyons C2, L45 
- 50); therefore, Lyons does not enable the storage of data in files or tables or the use of a 
common database. The Appellant notes that there are still other ways in which the §102 rejection 
of claim 65 can be traversed. As a result of these deficiencies, a prima facie case that would 
support the anticipation rejection of claim 65 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 66 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 65, does not enable all the 
elements of parent claim 65, provides insufficient detail regarding elements of parent claim 65 and 
that any alleged inherency of features of parent claim 65 has not been explained. The rejection of 
dependent claim 66 can also be traversed by noting that Lyons: is missing elements contained in 
claim 66, does not enable all the elements of claim 66, provides insufficient detail regarding 
elements of claim 66 and that any alleged inherency of features of claim 66 has not been 
explained. Elements of claim 66 not explicitly or inherently described in the Lyons document 
include a common data dictionary, a common set of attributes, categories of value, elements of 
value, and units of measure. Lyons also lacks detail regarding a common data dictionary, a 
common set of attributes, categories of value, elements of value, and units of measure and any 
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inherency of a common data dictionary, a common set of attributes, categories of value, elements 
of value, and units of measure has not been explained. Lyons also fails to enable categories of 
value, elements of value and units of measure. Lyons is limited to storing and manipulating 
information that appears in financial schedules (see page 37, Evidence Appendix, Lyons C2, L45 - 
50). It is well known to those of average skill in the art that financial schedules do not include the 
elements of value, categories of value and units of measure. Given these facts, it is clear that 
elements of value, categories of value and units of measure cannot be supported by Lyons. As a 
result of these deficiencies, a prima facie case that would support the anticipation rejection of claim 
66 has not been established. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to 
produce the evidence required to establish a prima facie case of anticipation for a single claim. 
The complete failure to identify anticipation at the claim level clearly illustrates the fact that the 
cited reference is not even remotely similar to the invention described by claim 65 and claim 66. 
As noted in MPEP 2112, anticipation requires that a substantial identity be established. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. 

Another reason claim 65 and claim 66 are patentable is that the prior art review for the instant 
application is apparently being completed under a different standard than that used for the review 
of similar patent applications - an apparent violation of 35 USC 3. As noted on page 46 in the 
evidence appendix and in the appeal brief for related application 10/282,113, the proper class for 
the invention described in claim 65 and claim 66 is class 707. The assignment to class 705 has 
resulted in the use of a different standard for prior art review than that used for similar applications 
properly classified in class 707. 

Issue 4 - Whether claim 67, claim 68, claim 69 and claim 70 are patentable under 35 USC 102 
over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

The claims are patentable for several reasons. One of the primary reasons is that the Lyons 
document and the arguments related to the Lyons document fail to establish a prima facie case of 
anticipation in a number of ways for every rejected claim. 

One way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to describe every element of 
the rejected claims. MPEP 2131 notes that: "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). 

Another way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to provide the same level of 
detail that is present in the claim. MPEP 2131 notes that anticipation requires that: "The identical 
invention must be shown in as complete detail as is contained in the ... claim." Richardson v. 
Suzuki Motor Co., 868 F. 2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

A third way in which the arguments related to the Lyons document fail to establish a prima 
facie case of anticipation for many if not all of the claims is there has been no disclosure of fact or 
technical reasoning that would support any allegations regarding inherent characteristics contained 
in the Lyons document. MPEP 2112 notes that: "In relying upon the theory of inherency, the 
Examiner must provide a basis in fact and/or technical reasoning to reasonably support the 
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determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
applied prior art." Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) 

The Appellant respectfully submits that the rejection of independent claim 67 can be traversed 
in four ways. The first way is by noting that several elements of claim 67 are not explicitly 
described in the Lyons document. The elements not explicitly described include: 

1. a common schema 

2. obtaining a plurality of data source data dictionaries, 

3. identifying a relationship between data source dictionaries and an application data 
dictionary, and 

4. aggregating data from a plurality of database management systems selected from the 
group consisting of an operations system, an accounts receivable system, an accounts 
payable system, a capital asset system, an inventory system, an invoicing system, a payroll 
system and a purchasing system. 

The second way is by noting that Lyons lacks detail regarding a common schema, obtaining a 
plurality of data source data dictionaries, identifying a relationship between data source dictionaries 
and an application data dictionary and aggregating enterprise related data from a plurality of 
database management systems selected from the group consisting of an operations system, an 
accounts receivable system, an accounts payable system, a capital asset system, an inventory 
system, an invoicing system, a payroll system and a purchasing system. The third way is by noting 
that any inherency of a common schema, obtaining a plurality of data source data dictionaries, 
identifying a relationship between data source dictionaries and an application data dictionary and 
aggregating enterprise related data from a plurality of database management systems selected 
from the group consisting of an operations system, an accounts receivable system, an accounts 
payable system, a capital asset system, an inventory system, an invoicing system, a payroll 
system, a purchasing system has not been explained. A fourth way of traversing the claim 
rejection is to note that the storage of data in a common, application database is not enabled by 
Lyons . Everest (a reference provided by the Examiner) teaches that databases that store data in 
files or tables use a finite number of logical data structures (see pages 40 - 48, Evidence 
Appendix). The Lyons database does not use any of these logical data structures (see page 37, 
Evidence Appendix, Lyons C2, L45 - 50); therefore, Lyons does not enable the storage of data in 
files or tables in a database that would support application processing. The Appellant notes that 
there are still other ways in which the §102 rejection of claim 67 can be traversed. As a result of 
these deficiencies, a prima facie case that would support the anticipation rejection of claim 67 has 
not been established. 

The Appellant respectfully submits that the rejection of dependent claim 68 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 67, does not enable all the 
elements of parent claim 67, provides insufficient detail regarding elements of parent claim 67 and 
that any alleged inherency of features of parent claim 67 has not been explained. The rejection of 
dependent claim 68 can also be traversed by noting that Lyons: is missing elements contained in 
claim 68, does not enable all the elements of claim 68, provides insufficient detail regarding 
elements of claim 68 and that any alleged inherency of features of claim 68 has not been 
explained. Elements of claim 68 not explicitly or inherently described in the Lyons document 
include forecast event data and historical event data. Lyons also lacks detail regarding forecast 
event data and historical event data and any inherency of forecast event data and historical event 
data has not been explained. Lyons also fails to enable forecast event data and historical event 
data. Lyons is limited to storing and manipulating information that appears in financial schedules 
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(see page 37, Evidence Appendix, Lyons C2, L45 - 50). It is well known to those of average skill 
in the art that financial schedules do not include forecast event data and historical event data. 
Given these facts, it is clear that forecast event data and historical event data cannot be supported 
by Lyons. As a result of these deficiencies, a prima facie case that would support the anticipation 
rejection of claim 68 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 69 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 67, does not enable all the 
elements of parent claim 67, provides insufficient detail regarding elements of parent claim 67 and 
that any alleged inherency of features of parent claim 67 has not been explained. The rejection of 
dependent claim 69 can also be traversed by noting that Lyons: is missing elements contained in 
claim 69, does not enable all the elements of claim 69, provides insufficient detail regarding 
elements of claim 69 and that any alleged inherency of features of claim 69 has not been 
explained. Elements of claim 69 not explicitly or inherently described in the Lyons document 
include a network model. Lyons also lacks detail regarding a network model and any inherency of 
a network model has not been explained. As a result of these deficiencies, a prima facie case that 
would support the anticipation rejection of claim 69 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 70 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 67, does not enable all the 
elements of parent claim 67, provides insufficient detail regarding elements of parent claim 67 and 
that any alleged inherency of features of parent claim 67 has not been explained. The rejection of 
dependent claim 70 can also be traversed by noting that Lyons: is missing elements contained in 
claim 70, does not enable all the elements of claim 70, provides insufficient detail regarding 
elements of claim 70 and that any alleged inherency of features of claim 70 has not been 
explained. Elements of claim 70 not explicitly or inherently described in the Lyons document 
include a common data dictionary, categories of value, elements of value, and units of measure. 
Lyons also lacks detail regarding a common data dictionary, categories of value, elements of 
value, and units of measure and any inherency of a common data dictionary, categories of value, 
elements of value, and units of measure has not been explained. Lyons also fails to enable 
categories of value, elements of value and units of measure. Lyons is limited to storing and 
manipulating information that appears in financial schedules (see page 37, Evidence Appendix, 
Lyons C2, L45 - 50). It is well known to those of average skill in the art that financial schedules do 
not include the elements of value, categories of value and units of measure. As a result of these 
deficiencies, a prima facie case that would support the anticipation rejection of claim 70 has not 
been established. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to 
produce the evidence required to establish a prima facie case of anticipation for a single claim. 
The complete failure to identify anticipation at the claim level clearly illustrates the fact that the 
cited reference is not even remotely similar to the claimed invention. As noted in MPEP 2112, 
anticipation requires that a substantial identity be established. Taken together, these failures 
provide additional evidence that the claimed invention for producing concrete, tangible and useful 
results is new, novel and non-obvious. 

Another reason claim 67, claim 68, claim 69 and claim 70 are patentable is that the prior art 
review for the instant application is apparently being completed under a different standard than that 
used for the review of similar patent applications - an apparent violation of 35 USC 3. As noted on 
page 46 in the evidence appendix and in the appeal brief for related application 10/282,113, the 
proper class for the invention described in claim 67, claim 68, claim 69 and claim 70 is class 707. 
The assignment to class 705 has resulted in the use of a different standard for prior art review than 
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that used for similar applications properly classified in class 707. 

Issue 5 - Whether claim 71, claim 72, claim 73, claim 74, claim 75 and claim 76 are 
patentable under 35 USC 102 over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

The claims are patentable for several reasons. One of the primary reasons is that the Lyons 
document and the arguments related to the Lyons document fail to establish a prima facie case of 
anticipation in a number of ways for every rejected claim. 

One way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to describe every element of 
the rejected claims. MPEP 2131 notes that: "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). 

Another way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to provide the same level of 
detail that is present in the claim. MPEP 2131 notes that anticipation requires that: "The identical 
invention must be shown in as complete detail as is contained in the ... claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

A third way in which the arguments related to the Lyons document fail to establish a prima 
facie case of anticipation for many if not all of the claims is there has been no disclosure of fact or 
technical reasoning that would support any allegations regarding inherent characteristics contained 
in the Lyons document. MPEP 2112 notes that: "In relying upon the theory of inherency, the 
Examiner must provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
applied prior art." Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) 

The Appellant respectfully submits that the rejection of independent claim 71 can be traversed 
by noting that Lyons: is missing elements contained in claim 71, does not enable all the elements 
of claim 71, provides insufficient detail regarding elements of claim 71 and that any alleged 
inherency of features of claim 71 has not been explained. Elements of claim 71 not explicitly or 
inherently described in the Lyons document include: 

1. a common schema 

2. obtaining a plurality of data source data dictionaries, 

3. identifying a relationship between data source dictionaries and an application data 
dictionary, and 

4. aggregating data from a plurality of database management systems. 

Lyons also lacks detail regarding a common schema, obtaining a plurality of data source data 
dictionaries, identifying a relationship between data source dictionaries and an application data 
dictionary and aggregating enterprise related data from a plurality of database management 
systems and any inherency of a common schema, obtaining a plurality of data source data 
dictionaries, identifying a relationship between data source dictionaries and an application data 
dictionary and aggregating enterprise related data from a plurality of database management 
systems has not been explained. Another way of traversing the claim rejection is to note that the 
storage of data in a common, application database is not enabled by Lyons . Everest (a reference 
provided by the Examiner) teaches that databases that store data in files or tables use a finite 
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number of logical data structures (see pages 40 - 48, Evidence Appendix). The Lyons database 
does not use any of these logical data structures (see page 37, Evidence Appendix, Lyons C2, L45 
- 50); therefore, Lyons does not enable the storage of data in files or tables in a database that 
would support application processing. The Appellant notes that there are still other ways in which 
the §102 rejection of claim 71 can be traversed. As a result of these deficiencies, a prima facie 
case that would support the anticipation rejection of claim 71 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 72 and 73 can be 
traversed by noting that Lyons: is missing elements contained in parent claim 71, does not enable 
all the elements of parent claim 71, provides insufficient detail regarding elements of parent claim 
71 and that any alleged inherency of features of parent claim 71 has not been explained. As a 
result of these deficiencies, a prima facie case that would support the anticipation rejection of 
claims 72 and 73 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 74 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 71, does not enable all the 
elements of parent claim 71, provides insufficient detail regarding elements of parent claim 71 and 
that any alleged inherency of features of parent claim 71 has not been explained. The rejection of 
dependent claim 74 can also be traversed by noting that Lyons: is missing elements contained in 
claim 74, does not enable all the elements of claim 74, provides insufficient detail regarding 
elements of claim 74 and that any alleged inherency of features of claim 74 has not been 
explained. Elements of claim 74 not explicitly or inherently described in the Lyons document 
include a sales system, an operations system, an accounts receivable system, an accounts 
payable system, a capital asset system, an inventory system, an invoicing system, a payroll 
system,, a purchasing system and an intranet. Lyons also lacks detail regarding a sales system, 
an operations system, an accounts receivable system, an accounts payable system, a capital 
asset system, an inventory system, an invoicing system, a payroll system,, a purchasing system 
and an intranet and any inherency of a sales system, an operations system, an accounts 
receivable system, an accounts payable system, a capital asset system, an inventory system, an 
invoicing system, a payroll system,, a purchasing system and an intranet has not been explained. 
As a result of these deficiencies, a prima facie case that would support the anticipation rejection of 
claim 74 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 75 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 71, does not enable all the 
elements of parent claim 71, provides insufficient detail regarding elements of parent claim 71 and 
that any alleged inherency of features of parent claim 71 has not been explained. The rejection of 
dependent claim 75 can also be traversed by noting that Lyons: is missing elements contained in 
claim 75, does not enable all the elements of claim 75, provides insufficient detail regarding 
elements of claim 75 and that any alleged inherency of features of claim 75 has not been 
explained. Elements of claim 75 not explicitly or inherently described in the Lyons document 
include a common data dictionary, categories of value, elements of value, and units of measure. 
Lyons also lacks detail regarding a common data dictionary, categories of value, elements of 
value, and units of measure and any inherency of a common data dictionary, categories of value, 
elements of value, and units of measure has not been explained. As a result of these deficiencies, 
a prima facie case that would support the anticipation rejection of claim 75 has not been 
established. 

The Appellant respectfully submits that the rejection of dependent claim 76 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 71, does not enable all the 
elements of parent claim 71, provides insufficient detail regarding elements of parent claim 71 and 
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that any alleged inherency of features of parent claim 71 has not been explained. As a result of 
these deficiencies, a prima facie case that would support the anticipation rejection of claim 76 has 
not been established. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to 
produce the evidence required to establish a prima facie case of anticipation for a single claim. 
The complete failure to identify anticipation at the claim level clearly illustrates the fact that the 
cited reference is not even remotely similar to the invention described in claim 71, claim 72, claim 
73, claim 74, claim 75 and claim 76. As noted in MPEP 2112, anticipation requires that a 
substantial identity be established. Taken together, these failures provide additional evidence that 
the claimed invention for producing concrete, tangible and useful results is new, novel and non- 
obvious. 

Another reason claim 71, claim 72, claim 73, claim 74, claim 75 and claim 76 are patentable is 
that the prior art review for the instant application is apparently being completed under a different 
standard than that used for the review of similar patent applications - an apparent violation of 35 
USC 3. As noted on page 46 in the evidence appendix and in the appeal brief for related 
application 10/282,113, the proper class for the invention described in claim 71, claim 72, claim 73, 
claim 74, claim 75 and claim 76 is class 707. The assignment to class 705 has resulted in the use 
of a different standard for prior art review than that used for similar applications properly classified 
in class 707. 

Issue 6 - Whether claim 77, claim 78, claim 79, claim 80 and claim 81 are patentable under 35 
USC 102 over U.S. Patent 4,989,141 (hereinafter, Lyons)? 

The claims are patentable for several reasons. One of the primary reasons is that the Lyons 
document and the arguments related to the Lyons document fail to establish a prima facie case of 
anticipation in a number of ways for every rejected claim. 

One way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to describe every element of 
the rejected claims. MPEP 2131 notes that: "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). 

Another way in which the Lyons document fails to establish a prima facie case of anticipation for 
many if not all of the rejected claims is that the Lyons document fails to provide the same level of 
detail that is present in the claim. MPEP 2131 notes that anticipation requires that: "The identical 
invention must be shown in as complete detail as is contained in the ... claim." Richardson v. 
Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

A third way in which the arguments related to the Lyons document fail to establish a prima 
facie case of anticipation for many if not all of the claims is there has been no disclosure of fact or 
technical reasoning that would support any allegations regarding inherent characteristics contained 
in the Lyons document. MPEP 2112 notes that: "In relying upon the theory of inherency, the 
Examiner must provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
applied prior art." Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) 

The Appellant respectfully submits that the rejection of independent claim 77 can be traversed 
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by noting that Lyons: is missing elements contained in claim 77, does not enable all the elements 
of claim 77, provides insufficient detail regarding elements of claim 77 and that any alleged 
inherency of features of claim 77 has not been explained. Elements of claim 77 not explicitly or 
inherently described in the Lyons document include: 

1. a common schema, 

2. a common network schema 

3. obtaining a plurality of data source data dictionaries via a back end interface, 

4. identifying a relationship between data source dictionaries and an application data 
dictionary, and 

5. aggregating data from a plurality of database management systems for a plurality of 
transaction systems. 

Lyons also lacks detail regarding a common schema, a common network schema, obtaining a 
plurality of data source data dictionaries via a back end interface, identifying a relationship between 
data source dictionaries and an application data dictionary and aggregating enterprise related data 
from a plurality of database management systems for a plurality of transaction systems and any 
inherency of a common schema, a common network schema, obtaining a plurality of data source 
data dictionaries via a back end interface, identifying a relationship between data source 
dictionaries and an application data dictionary and aggregating enterprise related data from a 
plurality of database management systems for a plurality of transaction systems has not been 
explained. Another way of traversing the claim rejection is to note that the storage of data in a 
common, application database is not enabled by Lyons . Everest (a reference provided by the 
Examiner) teaches that databases that store data in files or tables use a finite number of logical 
data structures (see pages 40 - 48, Evidence Appendix). The Lyons database does not use any of 
these logical data structures (see page 37, Evidence Appendix, Lyons C2, L45 - 50); therefore, 
Lyons does not enable the storage of data in files or tables in a database that would support 
application processing. The Appellant notes that there are still other ways in which the §102 
rejection of claim 77 can be traversed. As a result of these deficiencies, a prima facie case that 
would support the anticipation rejection of claim 77 has not been established. 

The Appellant respectfully submits that the rejection of dependent claim 78 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 77, does not enable all the 
elements of parent claim 77, provides insufficient detail regarding elements of parent claim 77 and 
that any alleged inherency of features of parent claim 77 has not been explained. As a result of 
these deficiencies, a prima facie case that would support the anticipation rejection of claim 78 has 
not been established. 

The Appellant respectfully submits that the rejection of dependent claim 79 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 77, does not enable all the 
elements of parent claim 77, provides insufficient detail regarding elements of parent claim 77 and 
that any alleged inherency of features of parent claim 77 has not been explained. The rejection of 
dependent claim 79 can also be traversed by noting that Lyons: is missing elements contained in 
claim 79, does not enable all the elements of claim 79, provides insufficient detail regarding 
elements of claim 79 and that any alleged inherency of features of claim 79 has not been 
explained. Elements of claim 79 not explicitly or inherently described in the Lyons document 
include accessing, converting, integrating and storing data from an Internet and any inherency of 
accessing, converting, integrating and storing data from an Internet has not been explained. As a 
result of these deficiencies, a prima facie case that would support the anticipation rejection of claim 
79 has not been established. 
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The Appellant respectfully submits that the rejection of dependent claim 80 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 77, does not enable all the 
elements of parent claim 77, provides insufficient detail regarding elements of parent claim 77 and 
that any alleged inherency of features of parent claim 77 has not been explained. The rejection of 
dependent claim 80 can also be traversed by noting that Lyons: is missing elements contained in 
claim 80, does not enable all the elements of claim 80, provides insufficient detail regarding 
elements of claim 80 and that any alleged inherency of features of claim 80 has not been 
explained. Elements of claim 80 not explicitly or inherently described in the Lyons document 
include a common data dictionary, categories of value, elements of value, and units of measure. 
Lyons also lacks detail regarding a common data dictionary, categories of value, elements of 
value, and units of measure and any inherency of a common data dictionary, categories of value, 
elements of value, and units of measure has not been explained. As a result of these deficiencies, 
a prima facie case that would support the anticipation rejection of claim 80 has not been 
established. 

The Appellant respectfully submits that the rejection of dependent claim 81 can be traversed 
by noting that Lyons: is missing elements contained in parent claim 77, does not enable all the 
elements of parent claim 77, provides insufficient detail regarding elements of parent claim 77 and 
that any alleged inherency of features of parent claim 77 has not been explained. The rejection of 
dependent claim 81 can also be traversed by noting that Lyons: is missing elements contained in 
claim 81, does not enable all the elements of claim 81, provides insufficient detail regarding 
elements of claim 81 and that any alleged inherency of features of claim 81 has not been 
explained. Elements of claim 81 not explicitly or inherently described in the Lyons document 
include a sales system, an operations system, an accounts receivable system, an accounts 
payable system, a capital asset system, an inventory system, an invoicing system, a payroll 
system,, a purchasing system and an intranet. Lyons also lacks detail regarding a sales system, 
an operations system, an accounts receivable system, an accounts payable system, a capital 
asset system, an inventory system, an invoicing system, a payroll system,, a purchasing system 
and an intranet and any inherency of a sales system, an operations system, an accounts 
receivable system, an accounts payable system, a capital asset system, an inventory system, an 
invoicing system, a payroll system,, a purchasing system and an intranet has not been explained. 
As a result of these deficiencies, a prima facie case that would support the anticipation rejection of 
claim 81 has not been established. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to 
produce the evidence required to establish a prima facie case of anticipation for a single claim. 
The complete failure to identify anticipation at the claim level clearly illustrates the fact that the 
cited reference is not even remotely similar to the invention described in claim 77, claim 78, claim 
79, claim 80 and claim 81 . As noted in MPEP 2112, anticipation requires that a substantial identity 
be established. Taken together, these failures provide additional evidence that the claimed 
invention for producing concrete, tangible and useful results is new, novel and non-obvious. 

Another reason claim 77, claim 78, claim 79, claim 80 and claim 81 are patentable is that the 
prior art review for the instant application is apparently being completed under a different standard 
than that used for the review of similar patent applications - an apparent violation of 35 USC 3. As 
noted on page 46 in the evidence appendix and in the appeal brief for related application 
10/282,113, the proper class for the invention described in claim 77, claim 78, claim 79, claim 80 
and claim 81 is class 707. The assignment to class 705 has resulted in the use of a different 
standard for prior art review than that used for similar applications properly classified in class 707. 
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Conclusion 

As detailed above, the evidence used to support the art rejections of the pending claws consists of 
a single document that fails to support an anticipation reaction for a single claim. The question as 
to whether an invention is anticipated by a prior art reference is a factual issue not a subjective one 
fin re Schrelber, 128 f.3d 1473, 14?? (Fed. Cir. 199?}}. ft is a fact mat Lyons does not enable or 

the Appellant respectfully but forcefully contends that each claim is oaisntabie. 
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Among other things ths Appellant specifically notes that 
a) At least some of the claims appear to he misctasslfied under class 70S. 
o) There appears to have been numerous instances of non-compliance vy;th MPEP 03; 
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reasons At least pad of the delay appears to have occurred because the Examiner refused to 
respond to reasonable requests for a copy of a missing office action: and 

d) The prior art review for the instant application appears to have been completed under a different 
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Therefore, reversal of all rejections is courteously solicited. 



CLAIMS APPENDIX 



44. A program storage device readable by a machine, tangibly embodying a program of 
instructions executable by the machine to perform method steps for performing a data method, the 
method steps comprising: aggregating enterprise related data from a plurality of database 
management systems in accordance with a common schema and storing said aggregated data in 
one or more tables or files to support processing. 

45. The program storage device of claim 44 wherein the enterprise related data are aggregated in 
accordance with a common data dictionary that identifies a common set of attributes selected from 
the group consisting of: category of value, component of value, element of value, currency, unit of 
measure and combinations thereof. 

46. The program storage device of claim 45, wherein the components of value are selected from 
the group consisting of revenue, expense, change in capital and combinations thereof. 

47. The program storage device of claim 45, wherein the elements of value are selected from the 
group consisting of brands, customers, employees, production equipment, strategic partnerships, 
vendor relationships and combinations thereof. 

48. The program storage device of claim 45, wherein at least part of enterprise-related data is 
entered for each point of time over a sequential series of points in time preceding a specified 
valuation date. 

49. The program storage device of claim 48, wherein the enterprise related data further comprise 
forecast event data and historical event data. 

50. The program storage device of claim 49, wherein the enterprise related data further 
comprises transaction data. 

51. The program storage device of claim 44 wherein said plurality of database management 
systems are obtained from the group consisting of advanced financial systems, basic financial 
systems, operation management systems, sales management systems, human resource systems, 
accounts receivable systems, accounts payable systems, capital asset systems, inventory 
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systems, invoicing systems, payroll systems, purchasing systems, the Internet and combinations 
thereof. 

52. The program storage device of claim 44, wherein the common schema further comprises a 
network model. 

53. A computer-implemented method, comprising: 

aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema and storing said aggregated data in one or more tables or files 
to support processing for enterprise analysis and modeling. 

54. The method of claim 53, wherein the enterprise related data are aggregated in accordance 
with a common data dictionary that identifies a common set of attributes selected from the group 
consisting of category of value, component of value, element of value, currency, unit of measure 
and combinations thereof. 

55. The method of claim 54, wherein one or more elements of value are selected from the group 
consisting of brands, customers, employees, production equipment, strategic partnerships, vendor 
relationships and combinations thereof. 

56. The method of claim 53, wherein enterprise related data further comprises forecast event data 
and historical event data. 

57. The method of claim 53, wherein the enterprise related data further comprises transaction 
data. 

58. The method of claim 53, wherein said plurality of database management systems are 
obtained from the group consisting of advanced financial systems, basic financial systems, 
operation management systems, sales management systems, human resource systems, accounts 
receivable systems, accounts payable systems, capital asset systems, inventory systems, invoicing 
systems, payroll systems, purchasing systems, the Internet and combinations thereof. 

59. The method of claim 53, wherein the common schema further comprises a network model. 
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65. A computer-implemented method, comprising: 

automatically aggregating enterprise related event data from a plurality of database management 
systems into files or tables in a common database, thereby converting the data into a format that 
supports a common schema for analyzing and modeling an enterprise. 

66. The method of claim 65, the method further comprising: 

using a common data dictionary to identify a common set of attributes in the enterprise related 
data from the plurality of database management systems, the attributes including at least one 
of: component of value, currency, element of value, unit of measure, or a combination thereof; 
automatically aggregating the enterprise related data from the plurality of database 
management systems using the identified common set of attributes. 

67. A computer readable medium having sequences of instructions stored therein, which when 
executed cause the processor in a computer to perform an enterprise data integration method, 
comprising: 

obtaining a plurality of data dictionaries and data from a plurality of data sources via a network 
connection, 

identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

converting said data source data to a common schema by using said relationships in an 
application software segment, and 

storing said converted data in an application database for use in processing 
where a plurality of data sources further comprise a plurality of database management 
systems for applications selected from the group consisting of a basic financial system, a 
human resource system, an advanced financial system, a sales system, an operations system, 
an accounts receivable system, an accounts payable system, a capital asset system, an 
inventory system, an invoicing system, a payroll system, a purchasing system and 
combinations thereof. 

68. The computer readable medium of claim 67, wherein a common schema is defined by an 
application database schema. 

69. The computer readable medium of claim 67, wherein a common schema further comprises a 
network schema. 
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70. The computer readable medium of claim 67, wherein a common schema contains a common 
data dictionary where said common data dictionary defines common attributes selected from the 
group consisting of elements of value, components of value, currencies, units of measure, time 
periods, dates and combinations thereof. 

71 . A data integration system, comprising: 

a computer with a processor having circuitry to execute instructions; 

a storage device available to said processor with sequences of instructions stored therein, an 
interface coupled to a plurality of data sources each of which has a data dictionary, and an 
application software segment which when executed causes the processor to: 
obtain a plurality of data dictionaries and data from the plurality of data sources, 
identify one or more relationships between each data source data dictionary and an 
application database data dictionary, 

convert said data source data to a common schema by using said relationships, and 
store said converted data in an application database for use in processing. 

72. The system of claim 71, wherein a plurality of data sources further comprise a plurality of 
relational databases that use different data formats. 

73. The system of claim 71 , wherein an interface further comprises a network connection. 

74. The system of claim 71, wherein a plurality of data sources further comprise database 
management systems for applications selected from the group consisting of a basic financial 
system, a human resource system, an advanced financial system, a sales system, an operations 
system, an accounts receivable system, an accounts payable system, a capital asset system, an 
inventory system, an invoicing system, a payroll system,, a purchasing system, an intranet and 
combinations thereof. 

75. The system of claim 71, wherein a common schema contains a common data dictionary that 
defines common attributes selected from the group consisting of elements of value, components of 
value, currencies, units of measure, time periods, dates and combinations thereof. 

76. The system of claim 71 , wherein a conversion of data to a common schema further comprises 



Serial No: 08/999,245 



33 



an conversion of data that is completed automatically. 

77. A computer implemented data integration method, comprising: 

accessing a plurality of enterprise data and data dictionaries via a back-end interface coupled to 
a plurality of data sources, 

identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

converting said enterprise data to a common schema by using said relationships in an 
application software segment, and 

storing said converted data in an application database for use in processing, 
where a common schema further comprises a network schema, and 

where a plurality of data sources further comprise database management systems for a 
plurality of enterprise transaction systems. 

78. The method of claim 77, wherein a back-end interface further comprises a network 
connection. 

79. The method of claim 77, wherein the method further comprises accessing, converting, 
integrating and storing data from an Internet. 

80. The method of claim 77, wherein a common schema further comprises a common data 
dictionary where said common data dictionary defines common attributes selected from the group 
consisting of elements of value, components of value, currencies, units of measure, time periods, 
dates and combinations thereof. 

81 . The method of claim 77, wherein a plurality of enterprise transaction systems are selected 
from the group consisting of a basic financial system, a human resource system, an advanced 
financial system, a sales system, an operations system, an accounts receivable system, an 
accounts payable system, a capital asset system, an inventory system, an invoicing system, a 
payroll system, a purchasing system, an Intranet and combinations thereof. 
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Evidence Appendix 

Pages 36 - 39 excerpt from Lyons document first cited October 20, 2006 
Pages 40 - 48 excerpt from Everest document entered October 12, 2006 
Page 49-52 4 pages returned to file wrapper on April 8, 2006 
Page 53-54 2 page petition response dated August 27, 2004 
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[57] ABSTRACT 
An advanced financial reporting and analysis software 
package is described. The package collects, organizes, 
manages and consolidates financial data and provides 
user defined capabilities for creating financial and cor- 
porate reports. Financial data is organized into four 
business classifications or dimensions: Schedule, Entity, 
Period and Type. Data is stored in the system in such a 
way that all data associated with a particular Schedule, 
Entity, Period and Type is identified by that particular 
SEPT value. To accommodate automatic data entry, a 
mapping means or template is provided that specifies 
for each different input spreadsheet the location of the 
first data cell in the spreadsheet and the size of the 
spreadsheet. Data is read from the data store by various 
report and spreadsheet generating functions which con- 
vert data associated with particular SEPT values to 
desired output formats. 
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COMPUTER SYSTEM FOR FINANCIAL 
ANALYSES AND REPORTING 

BACKGROUND OF THE INVENTION 5 
This relates generally to computer systems and more 
particularly to a computer software method and appara- 
tus for advanced financial applications such as general 
ledger, inventory, accounts payable, accounts receiv- 
able, financial and management reporting, and financial 10 
analysis and consolidation. 

Corporate software systems generally are divided 
into two categories. The first, basic financial systems, 
includes general ledger, accounts receivable and ac- 
counts payable systems. These systems include com- ^ 
puter worksheets and data bases. The second, advanced 
financial systems and processes, uses information from 
the basic financial systems to perform financial analysis 
and reporting functions. 

At present many of the basic financial systems- 20 
applications reside on micro computer software pack- 
ages. 

Worksheet applications allow the user to keep a two 
dimensional chart of his financial data on an electronic 
worksheet. Illustrative of such spread sheet applications 25 
is Lotus Development Corporation's LOTUS 1-2-3 ®. 
That program allows the user to set up two dimensional 
worksheets in the form of a grid made up of horizontal 
rows and vertical columns. Each intersection of a row 
or column forms a cell in which data can be stored in 30 
the form of numeric data (such as an account balance), 
text (such as an account name), or arithmetic operators 
(such as a formula which manipulates the contents of 
other cells). To enter data into a worksheet, the user 
will usually enter data via a keyboard, cell by cell. 35 
When users employ LOTUS 1-2-3 ® to perform more 
detailed analyses it is likely that they have also created 
complicated strings of commands (i.e., macros) to facili- 
tate data entry, management and reporting capabilities. 
Since these macros have been created by specific indi- 40 
viduals, they can be difficult to revise should business 
dictate. More important, because these macros are tai- 
lored to a user's personal needs, the application's useful- 
ness across the corporation is limited. 

These spreadsheet programs are also limited by their 45 
presentation of data in only two dimensions. This often 
requires considerable reorganization of the data before 
it can be used in advanced financial systems. 

Database packages such as Ashton Tate's dBASE 
III ® allow the user to keep a financial data base. Fre- 50 
quently, this information is needed for use in a report 
having a format different from that in which it is stored 
or in a spreadsheet such as that generated by one of the 
computer spreadsheets. However, report generation 
can be tedious and a great deal of data manipulation 55 
must be performed in order to load data from a data 
base into an electronic worksheet. For example, to load 
data from a data base to an electronic spreadsheet, the 
user must convert the data into an ASCII file and subse- 
quently download it into an electronic worksheet. 60 
When data is downloaded into a worksheet each field 
must be inserted into a cell. The downloading of data 
into the worksheet must be done with extreme care, 
otherwise cells containing formulas may be overwrit- 
ten. 65 

In addition to the above limitations, personal com- 
puter programs also generally lack the capacity to im- 
plement complex information management and finance 



controls such as audit trails and password protection 
capabilities needed in high-level financial applications. 

These programs also have the limitations that they 
are typing intensive with the result that the user must 
either acquire reasonable typing skills in order to use 
such programs efficiently or he must suffer considerable 
time penalties as he attempts to cope with extensive 
keyboard input. 

SUMMARY OF THE INVENTION 

The present invention is an advanced financial re- 
porting and analysis software package. The package 
collects, organizes, manages and consolidates financial 
data and provides user defined capabilities for creating 
financial and corporate reports. 

Data can be loaded into the computer system manu- 
ally as well as from known micro-computer packages 
such as LOTUS 1-2-3 ® and Ashton-Tate's dBase ® 
and also from departmental and corporate data bases 
and basic financial systems such as general ledger, ac- 
counts payable and inventory applications. The soft- 
ware package can also incorporate data from outside 
sources, such as Dow Jones News/Retrieval service to 
permit analysis of competitive financial data. 

Data is output from the financial data base of the 
present invention either into reports or directly into 
electronic worksheets. The data can be displayed in 
various ways allowing the user to use the system as an 
analysis tool as well as a production reporting system. 
The process of loading data base information into an 
electronic worksheet is far simpler than the method 
which must be employed when working with two sepa- 
rate conventional packages. 

In accordance with the invention, financial data is 
organized into four business classifications or dimen- 
sions: Schedule, Entity, Period and Type. Schedule 
identifies the kind of document the data comes from 
(e.g., an income statement, a tax schedule). Entity iden- 
tifies the reporting group within the business organiza- 
tion (e.g., departments, divisions, subsidiaries). Period 
identifies the range of time that the data represents (e.g., 
FY 87, Q2 87). Type provides an additional dimension 
that can be used to further categorize the data (e.g., 
actual, budget, forecast). 

Data is stored in the system in such a way that all data 
associated with a particular Schedule, Entity, Period 
and Type (SEPT) is identified by that particular SEPT 
value and is stored in a predetermined pattern relative 
to the location of that SEPT value in the data store. 

To accommodate automatic data entry, a mapping 
means or template is provided that specifies for each 
different input spreadsheet the location of the first data 
cell in the spreadsheet and the size of the spreadsheet. 
From this information, the system is able to locate the 
data in the spreadsheet and read it systematically into 
the data store. 

Data is read from the data store by various report and 
spreadsheet generating functions which convert data 
associated with particular SEPT values to desired out- 
put formats. For example, one such function might map 
data associated with the same Schedule, Entity and 
Type but consectuive Periods over several years onto a 
spreadsheet having as many columns as there are Peri- 
ods so as to produce a spreadsheet showing the varia- 
tion of such data over time. 

One function of the present invention is to consoli- 
date information that arrives at corporation's headquar- 
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ters in multiple formats from the corporation's numer- The personal computers illustratively are IBM-PC's 
ous divisions and subsidiaries. Through usercontrolled or clones or any of the more advanced personal corn- 
dictionaries within its user interface, the computer ap- puters now available. As is well known such computers 
plication standardizes the way financial information is include a processor, a read/write memory and means 
managed and analyzed within a corporation. In addi- 5 for writing data into said memory and reading data 
tion, the system allows for hierarchical mapping so that from said memory. Typical memory configurations 
subsidiaries are attached to the controlling entities. used with the present invention should include at least 
Therefore, when data is input into the data base so as to 640 Kilobytes of semiconductor random access memory 
update an entry, all entities which are attached to the and at least a 10 megabyte hard disk. Each such corn- 
updated entity are also updated. 10 puter includes a video display 32, a printer 34, and a 

Other features of the invention include a modeling keyboard 36 that provides for alphanumeric input, func- 

function which is integrated with the data store so that tion keys and a cursor control. Data can be input from 

data associated with any SEPT value can be recalled for the keyboard or from computer files such as electronic 

use in calculating the model or for comparison with the worksheets. Data can be output to printed reports and 

model. 15 to electronic worksheets. 

In addition to financial and management reporting Unlike conventional data base management systems 

and analysis, other application areas include interna- or worksheet applications, the system of the present 

tional planning and analysis, consolidation and tax anal- invention allows for a four dimensional analysis of all 

ysis and the like. Reporting functions include currency financial data. In particular, the data stored in the sys- 

conversion, journal entries, hierarchy roll-ups and com- 20 tern is organized into four business classifications or 

putation of year to date totals and variances. Additional dimensions, namely Schedule, Entity, Period and Type 

features include audit trails and data verification. (SEPT). Schedule identifies the type of document the 

The present invention may be used as a stand alone data comes from (e.g., income statements, budgets, tax 

system, but is preferably for departmental use. The schedules) Entity identifies a reporting group within the 

financial computer system and process is designed for organization (e.g., departments, subsidiaries). Period 

use by all levels of employees who are involved in finan- identifies the time that the data represents (e.g., FY 87, 

cial control, whether it be a firm's chief financial officer Q2 87). Type provides an additional dimension that 

or an end user in the financial department. allows the user to further categorize data (e.g., actual, 

The financial system of the present invention is pres- 30 budgeted, forecast), 

ently sold commercially by the assignee as the FAS- In storage, all the data associated with a particular 

TAR tm financial computer program. Further details Schedule, Entity, Period and Type is identified by that 

of the operation of the system are set forth in the FAS- particular SEPT value. Thus, the system data base can 

TAR TM Tutorial, Reference Guide, Quick Reference, be represented as follows: 

Modeling Guide, and Modeling Quick Reference avail- 3 
able from the assignee, which are incorporated here by 
reference. 



Si, Ei, Pi, Tt, datacelli, . . . datacell* 
Sic, Ei, P m , T„, datacelli, . . . datacellj, 



BRIEF DESCRIPTION OF DRAWINGS 

^ , , , , „ where the number of SEPT values can be as great as the 
These and other objects, features and advantages of 40 duct of the numbers of ScheduleS; EntitieSi Periods 

the invention will be more readily apparent from the and T f kn * m * n) and the number of data cells 

following description of a preferred embodiment of the ^^ted with each SE PT value can vary, 

invention in which: In addition to the data base, the system of the present 

FIG. 1 is a system overview of an illustrative com- - 



, . , . . , . . invention also provides a means of mapping input data 

puter system used in the practice of the invention; 45 from hs SQmce tQ the location in {he database assi d 

FIG 2 is a flow chart depicting the user's interaction tQ {he particular SEPT value with which it is ^ocmied 

W1 * ' J?.fy st f m; _ , , . . ... and means for mapping data from the database location 

FIGS 3A-6B are flowcharts depicting the implemen- ^ d tQ the SEpT vaJues t0 m format Jhe 

ta ™^o ^„ Creat „ e fUn ? 10n ° f ^.P"^ invention; m ; means ig feferred tQ bdow as an . 

FIGS. 7-18 are flowcharts depicting the implementa- 50 template .^ ev = r al output mapping means are described 

"^i^T 1 fu " ctlon , of th ? P resent lnve "; below for the generation of output reports or files. 
FIGS 19-23 are flowcharts depicting the implemen- when retrievin data from ^ s ^ the user can 

tation of the Query function of the present invention; spedfy data ffom different categories in each of the 

an „ T _,_ „„ „, „ it _ • , dimensions. For example, the user may have defined a 

FIGS 24-26 are flowcharts depicting the implemen- 55 data base with the following SEPT entries: 
tation of the Pop-up function of the present invention. 



SCHEDULES ENTITIES PERIODS 



Income statement Corporate Ql 87 Actual 

As shown in FIG. 1, the preferred embodiment of the 60 Balance Sheet U.S. Q2 87 Budgeted 
invention is a computer system 20 illustratively com- Sales Budget Far East Q3 87 Forecast 
prising a plurality of personal computers 30 and an Tax Schedule Europe Q4 87 Q4Var 
interconnection network 40. The system can be net- 
worked to twenty-five users or more. Resident in the The user could then retrieve data on the basis of any 
memory of one of the computers 30 and accessible to all 65 combination of the categories found in each of the four 
of them is the data base management program of the dimensions. For example, the user could request: 
present invention which provides for advanced query Schedule = Sales Budget 
and analysis functions. Entity = U.S., Far East 
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Set-Up 



Before the data h 



anagement system can operate, 
it needs an "outline" of the user's financial organization. 
For example, it must know which subsidiaries, send data, 5 
the currencies these subsidiaries use and the currency 
conversion rules. This information is supplied by six 
dictionaries. The data base management system also 
needs to know the relationship or hierarchical organiza- 
tion of the entities that constitute the financial organiza- 10 
tion. 

Other features of the present invention include auto- 
matic data entry from input files or worksheets into the 
system's data base and checking for integrity errors. To 
accommodate this automatic data entry, a mapping 15 
means or template must be created that specifies for 
each different input worksheet, the location of the first 
data cell in the worksheet and the size of the worksheet. 
From this information, the system is able to locate the 
data in the worksheet and read it systematically into the 20 
data store. 

These and other set-up procedures are accomplished 
by selection of the CREATE function on the screen 
depicted in Table I. As shown in Table II, the CRE- 
ATE function has six subfunctions: INPUT—TEM- 25 
PLATE, HIERARCHY, DICTIONARY, RANGE, 
X-INTEGRITY and SETUP and each of these sub- 
functions has available to it a menu of sub-subfunctions 
such as ADD, MODIFY, DELETE, LIST. 
TABLE II 

May 20. 1987 copyright (5) 1986 Corp. Class Software 



a Period. The other dictionary values are then defined 
for that period as well. For each additional period that 
is defined in the period dictionary, the remaining dictio- 
nary values must again be defined. Suice these values 
are often the same over many different periods, this can 
usually be done simply by allowing the system to copy 
such values over for each additional period. 

The RANGE function permits the user to define the 
categories into which the data is organized in the system 
by providing a pointer between a name and a datacell 
associated with a particular SEPT value. By assigning 
the same name to several data cells each associated with 
a different SEPT value, the user can extract data from 
each of these data cells by using the one name rather 
than by specifying the location of each of the data cells. 

X—INTEGRITY permits the user to set up the cross- 
integrity checks. For example, the data in the Income 
Statement can be compared against data in the Balance 
Sheet to see if they are equal. If the data is incorrect the 
system will prompt the user with an error. A status/er- 
ror report listing integrity errors is also available at this 
point. This is part of the audit trail which is provided by 
the system. 

The set-up functions (create and INPUT) allow the 
user to do certain administrative tasks such as create 
user passwords, enter data into system dictionaries, set 
default periods and types, and specify printer configura- 

The dictionaries form the basic structure of the sys- 



CREATE INPUT QUERY ANALYZE REPORT TRANSFER MAINTAIN X-RUN 



DICTIONARY 



RANGE 

X INTEGRITY 

SETUP 



it template format, integrity rules and descriptions. 



Table II illustrates the addition of entries in the DIC- 
TIONARY subfunction. The CREATE, DICTIO- 
NARY and ADD functions are all highlighted as 
shown by a line above and below each of these func- 
tions. 50 

The INPUT-TEMPLATE function allows the user 
to build templates which are used as structured gate- 
ways for inputting data. All data passes through one of 
these templates before being stored in the data base. 

The HIERARCHY function allows the user to define 55 
the structure of the corporation for financial analysis. A 
hierarchy entity is the entity into which a specified 
group of other entities, called detailed entities, can be 
consolidated. The HIERARCHY function defines the 
order in which data can be automatically rolled-up from 60 
detailed entities to hierarchial entities. 

The dictionaries are defined by the DICTIONARY 
function. There are six dictionaries for Period, Type, 
Entity, Currency Rate Code, Currency Rate Type and 
Account Description. These dictionaries are the first 65 
thing to be defined in setting up a system; and since the 
other dictionary entries are all defined relative to a 
specific period, the first dictionary entry to be defined is 



tern's data bases. Each function of the system refers to 
these dictionaries in order to validate data while pro- 
cessing. For example, if the user desires to input data for 
the first quarter of 1987 he must first enter this period in 
the Period Dictionary as Ql 87. 

The preferred embodiment of the present invention 
uses six defined dictionaries. The following five dictio- 
naries are required: 

Period — To specify time* periods such as Quarter, 
Year, Month and Day. The data base management sys- 
tem's operation is based on time periods which are spec- 
ified by the user to conform to the user's unique report- 
ing needs. All data is input for a specific period and all 
other dictionary entries are defined for that period. 

Type — To specify the types of data being reported 
and analyzed. Common types are Actual, Standard 
Budget, and Forecast but the user may use and type any 
name he wishes. 

Currency Rate Codes — To specify the currencies in 
which the user does business, such as dollar, peso, or 
yen. 



50 
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The previous chapter established a classification of DBMSs based upon functions 
broadly grouped by user type. This chapter examines and classifies DBMSs based 
upon the class of data structures which can be defined in and processed by the DBMS. 
The next chapter classifies DBMSs based upon their user interface and language. 

In any evaluation of DBMS it is necessary to consider both the types of data 
structures definable in the system and the languages or methods provided for process- 
ing those structures. A very rich data structuring capability is useless without compre- 
hensive, high-level languages and facilities for processing and manipulating the data. 
Conversely, the design of a data language depends partly upon the data structure — a 
more complex data structure class with several different data constructs requires more 
operations to be expressed in the language. 



4.1 A TAXONOMY OF DATA STRUCTURES 

In current DBMS literature, systems are most often classified according to the 
logical structure of the underlying data "model,"* that is, the class of data structures 
which can be defined in and processed by a given DBMS. A database is formally 
defined to a DBMS by writing statements in its Data Definition Language (DDL). 

The following paragraphs introduce the taxonomy of data structures by naming 
and briefly describing various types of structures. At this point the reader should 
visualize the taxonomy as presented in Figure 4-1. This brief overview provides an 
initial understanding by placing the pieces of the taxonomy into a consistent, overall 
picture. Subsequent sections further describe each part of the taxonomy, thus providing 
a deeper understanding. 

Let's start'!' with the proposition that a database is a collection of information about 
entities (people, organizations, positions, policies, orders, parts, projects, events, 
etc.). Attributes describe entities (e.g., age of person, budget of organization). A 
particular entity ("instance") is described by the values of a set of attributes. (Age of 
"John Doe" is 41). The database designer selects some set of attributes to describe 
entities in the database. 

The first division in the taxonomy of data structures is based upon whether or not 
the attributes or data items are grouped into records. (Records represent entities). 
Historically, most data structures have been record-based. Most people in data process- 
ing are familiar with collections of data consisting of files of records. Assuming a 
grouping of data items at the outset of database design leads to some difficulties in the 
resulting structures, particularly when they expand to encompass more of the data in an 
organization. Recognizing these limitations, several authors [notably Abrial (1974); 
Senko (1976), Nijssen (1976 and 1977), and Kent (1979)] have proposed a class of 

*The icnn "model" is widely used although il is somewhat misleading: The phrase "data structure 
class" is more accurate. Something is a "model" if it bears a likeness to or is an imitation of something else. 
A defined database is a data model of reality to the users; a DBMS is a data modeling system. 

f I'his is not the only place to start a discussion of data structures. For another see: Tsichrit/.is and 
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DATA STRUCTURES 
- GROUPED ITEMS - 



- SINGLE FILE - 



■i SINGLE FLAT FILE - A single record type with 

I 1 single-valued data items 

- no repeating items or groups of i 



■i SINGLE HIERARCHICAL FILE 



nested repeating groups o1 



| ORG, unit] 
I PERSON I 



I ORG. UNIT I 



| PERSON "j | POSITION | | PROJECT j 
| SKILL [ 

■j MULTIFILE STRUCTURE I - data items grouped into multiple entry types 
1 - relationships defined between entry types (files) 

- some drop the term "file" and call this a "database" 

- each entry type (or "file") may have a flat 
or a hierarchical data structure (see SINGLE FILE) 



I ORG. UNIT I } 



- GENERAL INTER FILE RELATIONSHIPS 

Many, Many:Many relationships HEAD^. 

[person ^ position I 

- UNGROUPED ITEMS - | OBJECT-RELATION STRUCTURE~j 
- no prior grouping of 

— 8INARY RELATIONS BETWEEN OBJECT DOMAINS 
*— IRREDUCIBLE N-ARY RELATIONS BETWEEN OBJECT DOMAINS 

Figure 4-1. A Taxonomy or Data Structures. 
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dala structures which omit the dual notion of entity-attribute, replacing it with the 
single notion of "object." These are called the object-relation class of data structures, 
explained at the end of this chapter. 

Data structures with grouped items can first be divided into single-file structures 
and multifile structures. In a single-file structure, all information in the database can 
be grouped according to a single entry type. In other words, there is one primary entity 
connotation for the entire database. Single-file structures are further divided into flat 
file structures and hierarchical file structures. In a single hierarchical file structure, 
each primary entity may have subentities (that is, the primary record, corresponding to 
the primary entity, contains nested repeating groups of data items representing attri- 
butes of the subentities). Single hierarchical structures are further divided into single 
path and multipath ("branching") hierarchical file structures or data structures. 

A multifile data structure consists of multiple, related files. All the data items in 
the database are grouped into multiple record types. There is no longer one primary 
entity or record type in the database. Entities may exist independently of each other and 
may be related to each other. Multifile data structures offer greater flexibility than 
single-file structures, therefore, enabling greater fidelity in modeling the world of 
interest to the user(s). 

Multifile data structures are further divided into those which only permit a hier- 
archical relationship between entity types and those which permit a general relationship 
between entity types. (Multifile data structures are also further divided depending on 
whether each file must be flat or may be a hierarchical structure.) 

4.1.1 Only What the System Knows 

In all cases, what can be formally defined in a DDL to a DBMS determines the 
data structure class. The data structure class is based upon what the system knows 
about the data structure. Generally, the users will know more, much more, than the 
system knows about the meaning of a particular data structure. 

4.1.2 The Three "Great" Data Structures 

It has become popular to classify DBMSs into three groups based upon the under- 
lying data structure class [Date, 1981: Ulman, 1980]. The understanding of each type 
is based upon a particular system or proposal: 



Hierarchical IMS from IBM. or SYSTEM 2000 from Intel. 

Network CODASYL DBTG Proposal now embodied in a DDL and DML. 

Relational based on the work of E. F. Codd. now embodied in SQL from IBM. 



Language is associated with these examples of each data structure class. It is a 
common mistake to evaluate the data structure by the language available for processing 
that structure. Comparing the low-level languages of IMS and the CODASYL DML to 
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15.5 DATABASE ADMINISTRATOR TOOL: 
THE DATA DICTIONARY 

Several computer-based tools have emerged to satisfy various functions of 
database administration. These include tools for: 



DATABASE INTEGRITY MAINTENANCE 




• Backup and recover (dump and load) data. 

• Check the stored data to ensure that it conforms to its definition and sat 


sfies defined valida- 


• Analyze monitoring and audit trail logs for evidence of any suspiciou 

• Trace all chains in the stored data to ensure that all pointers arc valid am 

are connected. 


activity or problem 
that all stored pieces 


DATABASE REVISION 




• Redefine a stored database. 

• Restructure the database to conform to the new definition. 




PERFORMANCE MONITORING AND IMPROVEMENT 




• Analyze monitoring logs for changing trends in database usage. 

• Determine storage space utilization and recover space left by logically (but not physically) 

deleted data. 

• Reorganize stored data by folding in data from overflow areas and physically reordering 

stored records. 

• Reorganize file search and access mechanisms; rebalance indexes. 


DATABASE DESIGN 




• Check a proposed design for consistency. 

• Generate a graphical data structure diagram from a proposed definitio 

• Provide estimates of file size and performance. 





Most of these tools require information about the database. From a broader perspec- 
tive, the database administrator, users, and the DBMS all require information about the 
database. Ideally, such information should be stored in one central place. This is the 
role of the data dictionary, or dictionary/directory. A data dictionary is the main tool of 
database administration. 

A dictionary provides definitions of things. 
A directory tells you where to find them. 

A data dictionary/directory contains information (or data) about data. 

More recently, data dictionaries have been extended to provide information on other 
entities as they relate to data — programs, external input transactions and output re- 
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ports, userschemas, and users. The phrase information system resource dictionary has 
been used to reflect this broader perspective. Allen, Loomis, and Mannino [1982] 
simply dropped the limiting designation of "data" and used the phrase "integrated 
dictionary/directory." Furthermore, the term "catalogue" is sometimes used to better 
reflect the broader perspective than is implied by the traditional notion of a dictionary. 
Nevertheless, the term data dictionary still persists and is used here to encompass an 
information system resource catalogue. 

The information system resource catalogue, or simply "data dictionary," is a 
DBA tool for an organization to maintain information relating to the various resources 
used in information systems — data, input transactions, output reports, programs, ap- 
plication systems, and users. The information about nondata entities is maintained 
primarily as they relate to the data entities. 

Historically, data dictionary systems evolved to satisfy the need for more complete 
information about data stored in a database than was provided by the database schema. 
Some early DBMSs provided a very sketchy definition of a database — sufficient for 
machine access and processing but not sufficient for the people who had to use and 
manage the data [see Cahill, 1970; Uhrowczik, 1973]. There was (and is) also a need 
to provide a repository of data about data to support the systems analysis and design 
process, before formally defining the data to a DBMS (or in application programs). 

15.5.1 Providing a More Complete Definition of Data 

When the database definition is formalized in the database definition language 
(DDL) of a DBMS, it contains sufficient information to enable machine processing. 
For the people in the using environment, the DDL statements and graphical representa- 
tion usually contain insufficient information. The DDL only needs to be complete 
enough for the machine to be able to store data and subsequently retrieve it. Many 
DDLs contain substantially less information than was discussed in Chapter 6. They 
only give the tip of the iceberg of "data about data." 

Nevertheless, the more complete the formal database definition, the less the need 
for a data dictionary to "complete" the definition of the data within the system. A data 
dictionary supplements a database definition; it is like a "super" database definition. 
Conversely, the database definition is (or should be) a subset of the information in the 
data dictionary. That is, all the information required for the formal database definition 
should be derivable from the information in the data dictionary. 

This is the critical element of the data dictionary/directory system proposed by 
Plagman and Altshuler [1972]. They argue that an integrated corporate database sys- 
tem be driven by one central definition for both people and processes, including the 
DBMS. When a system contains both a stored database definition and a mechanized 
data dictionary which are separate and largely independent, there is no assurance that 
the definitional information in the two will be consistent. The database definition 
informational needs of the DBMS should be derived from the data dictionary/directory. 
This reduces the dependence on the currently installed DBMS. 

The following points indicate the kinds of information that could be stored in a 
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data dictionary. The list goes substantially beyond the database definition information 
discussed in Chapter 6 to include information needed for database administration. 
Although the primary focus is on data about data items (or data "elements"), some 
information pertains to other structural elements. 

• Name — short name, full name, and name aliases or synonyms as used in the DBMS or 

in programs (e.g.. names in COBOL). May include long forms of the name 
perhaps developed from some hierarchical classification scheme or highly struc- 
tured naming scheme (see following section for an outline of one such scheme 
called the "OF language'). 

• Description or explanation; meaning, interpretation rules and guidelines; purpose of 

the data item and why it is kept. 

• Owner — delegated responsibility for creation, maintenance, and integrity of the data 

item values. 

• Date of creation and date of last update of this dictionary entry. 

• Value set designation by type, ranges or enumeration of values, the meaning of attri- 

bute values and codes, and values for the null slates of unknown and irrelevant. 

• Internal format and size. 

• External display format, and default column heading on reports. 

• Unit of measurement. 

• Derivation rule or algorithm, if applicable. 

• Validation criteria and editing rules. 

• Subjective expression of reliability or validity of the data. 

• Conditions for existence or relevance: mandatory or optional. 

• Frequency of generation and change; useful life. 

• Where the data is stored and how to get it; based on relationships. 

• Relationship to other data in the database — from a common domain of values. 

• Relationship to other entities in the system — computer installations, application sys- 

tems, programs, files (record types), external data collection forms and input 
transactions, output reports, userschemas. 

• How the data is used (created, added, read, modified, deleted) by related process 

entities (programs). 

Providing a more complete database definition, the data dictionary serves several 
purposes. It is used by the DBA to support design activities and control responsibili- 
ties. It can be used by consumers (users) of data to find out what data is available, what 
the data means, and where and how to get it. 

15.5.2 Uses of a Data Dictionary 

A comprehensive data dictionary provides the definition of data items, how they 
fit into a data structure, and how they relate to other entities in the information system 
environment. The types of entities can be classified as follows: 

• Data — data item, record type (group, segment), database. 

• Processes — computer installation, application system, program, module. 

• External inputs and outputs — transaction, form, report, display screen, userschema. 
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• Users — individual, group, organizational unit, terminal — any of which may be the 

source or user (destination) of data, or the point of responsibility for the creation 
and maintenance of data. 

The foundation of the data dictionary is information about data items. With a 
comprehensive base of information, the data dictionary can serve several useful pur- 
poses. These purposes span the whole spectrum of planning, determining information 
requirements, design and implementation, operation, and revision. 

• Documentation — providing reports of data about data. The data dictionary can be used 

to generate a graphical representation of the database structure similar to auto- 
matic program flowcharting. 

• Data availability — a data map for end users to discover what data exists in the organi- 

zation, what it means, where it is stored, and how to access it. May be provided 
using a facility for browsing through a data dictionary. 

• Design — a tool to support the processes of database design and systems analysis and 

design. A data dictionary can contain the latest proposed contents of a database as 
a design evolves. 

• Schema generation — automatic generation of the DDL for a target DBMS to serve as 

the vehicle for implementing a database. 

• Change control — setting and enforcing standards; evaluating the impact of proposed 

changes and implementing those changes. 

In a general sense, the data dictionary is a vehicle for managing size and complexity in 
a database environment. In a typical, single-function organization (not a mixed con- 
glomerate) the individual data items will number in the several thousand. The data 
items appear in hundreds of files (record types) which are interrelated, and in hundreds 
of input transactions or data capture screens and output reports. In fact, these numbers 
tend to be relatively independent of organization size; at least they are not linearly 
proportional to organization size. 

15.5.3 For Systems Analysis and Design 

For purposes of systems analysis and design, the data dictionary results from 
taking inventory of all the data in an organization (or a particular application system). 
This inventory of existing data can be refined, and it can be extended with new data 
requirements. 

In building a data dictionary, the primary focus is a description of existing data, 
that is, the collection of data about all existing data within an organization whether 
mechanized or not. The process of collecting data about data is a necessary' step in the 
analysis of an existing system to discover: 

• Data Hows, sources, and destinations. 

• Redundant data within the system. 

• Multiple descriptions of the same data and similar descriptions for different data. 

• Something about the tasks which create, process, use, move, and store data. 

The methodology of inventorying data usually revolves around the groupings of 
data on input forms, in manual and mechanized files, and on output reports, all of 
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In re Application of 

Jeffrey S. Eder DECISION ON PETITION 

Application No. 08/999,245 TO WITHDRAW THE 

Filed: December 10, 1997 : HOLDING OF ABANDONMENT 

For: A METHOD OF AND A SYSTEM FOR 

DEFINING AND VALUING ELEMENTS OF 
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This is in response to applicant's letter of December 14, 2001 requesting a copy of the Office 
action mailed on November 21 ,2000. This letter is being construed as a petition to withdraw 
the holding of abandonment under 37 CFR 1.181. The delay is considering this petition is 
sincerely regretted. 

The petition is GRANTED . 

A review of the file record indicates that this application was held abandoned on December 7, 
2001 for failure to respond to the Office action within the statutory period of three months from 
the mailing date of November 21 , 2000. 

Applicant submits that the Office action was never received. 

A review of the file reveals that a Revocation and Substitute Power of Attorney was filed 
September 5, 2000 and was entered into the file wrapper. However, it appears the papers 
were never processed and entered into the USPTO database. Thus, the Office action was not 
mailed to the new attorney of record, Todd M. Becker of Davis, Wright, Tremaine, LLP at the 
firm's address of 2600 Century Square, 1501 Fourth Avenue, Seattle, Washington 98101- 
1688. Subsequently, applicant filed another Revocation of Power of Attorney on March 16, 
2001 that revoked all previous powers and returned power to applicant. This document was 
processed and a Notice to that effect was mailed on March 22, 2001 , but the Office action of 
November 21 , 2000 had been previously sent to the incorrect address and was never provided 
to applicant. 
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The application is being forwarded to the Supervisory Legal Instruments Examiner with 
instructions to withdraw the holding of abandonment and restore the application to pending 
status before re-dating and re-mailing the Office action to the updated correspondence 
address. 



Randolph fit. Reese 
Special Programs Examiner 
Technology Center 3600 
(703) 308-2121 

RAR: 8/25/04 



Serial No.: 08/999,245 54 




Related Proceedings Appendix 



None 



Serial No: 08/999,245 



55 



